Systems and Methods for Performing Workflow

ABSTRACT

The systems and methods of the invention provide a workflow system for processing a financial application in an automated manner. The workflow system may include an interface portion, the interface portion inputting application information into the workflow system for processing by the workflow system and a workflow looping portion. The workflow looping portion may include performing underwriting processing to effect underwriting of the application based on the application information, performing issue processing to effect issue of the application, and performing settlement processing to effect settlement of the application. A rules logic portion may be provided to control the implementation of rules applied to the processing of the application as the application passes through the automated processing. The performing underwriting processing, performing issue processing and performing settlement processing are each performed in an automated manner to constitute automated processing of the application, such that the automated processing includes the performing underwriting processing, performing issue processing and performing settlement processing.

This patent application is a continuation of U.S. patent applicationSer. No. 10/944,184 filed on Sep. 20, 2004 entitled “SYSTEMS AND METHODSFOR PERFORMING WORKFLOW” (Attorney Docket No. 52493.000351). Thisapplication is also related to U.S. application Ser. No. 10/944,185filed Sep. 20, 2004 (Attorney Docket Number 52493.000122) entitledSYSTEMS AND METHODS FOR PROVIDING ACCESS TO AN IMAGE, all of which areincorporated herein their entirety.

BACKGROUND OF THE INVENTION

The systems and methods of the invention are directed to the processingof applications in the financial services industry.

In the financial services industry, applications for a financial productor service come into a firm or other company environment. Theseapplications are obtained from any of a wide variety of sources andtypically respectively pertain to a variety of products offered by theparticular company. The effective and efficient processing of suchapplications are critical to the survival of a financial servicesentity. However, the processing of these applications are very complexdue to various reasons, including the needed detail involved in suchapplications. Processing of the applications are further complicated bythe mandates of state and federal regulations. These regulations areoften situation dependent making processing of applications morecomplex. Adding further complexity is the fact that applicableregulations often vary between states. A further known complication iseffectively accessing and using documents that are needed for processingof applications. As one can imagine, effective access to neededdocuments is critical to business success in a highly competitivemarket.

As is known, the processing of an application in the financial servicesindustry, such as an insurance application, involves many phases. For aninsurance application, these phases might include the initial processingof an application, interacting with the customer to secure needed itemsor information, and then underwriting of the application. However,various other phases may be involved in the processing of an insuranceapplication, not to mention the processing of other financial products.

As might be expected, various approaches are known to effect theprocessing of such applications in the financial services industry. Atthe most basic level, such applications are processed by hand, movingfrom one person to another as the application process proceeds. However,known processes fail to provide the automation and functionality neededto process such applications in an efficient and effective manner.

The methods and systems of the invention address the above, as well asother problems and shortcomings of known techniques for processingapplications.

BRIEF SUMMARY OF THE INVENTION

The systems and methods of the invention provide a workflow system forprocessing a financial application in an automated manner. The workflowsystem may include an interface portion, the interface portion inputtingapplication information into the workflow system for processing by theworkflow system and a workflow looping portion. The workflow loopingportion may include performing underwriting processing to effectunderwriting of the application based on the application information,performing issue processing to effect issue of the application, andperforming settlement processing to effect settlement of theapplication. A rules logic portion may be provided to control theimplementation of rules applied to the processing of the application asthe application passes through the automated processing. The performingunderwriting processing, performing issue processing and performingsettlement processing are each performed in an automated manner toconstitute automated processing of the application, such that theautomated processing includes the performing underwriting processing,performing issue processing and performing settlement processing.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention can be more fully understood by reading thefollowing detailed description together with the accompanying drawings,in which like reference indicators are used to designate like elements,and in which:

FIG. 1 is a high level diagram showing a workflow system with workflowprocessing in accordance with one embodiment of the invention;

FIG. 2 is a block diagram showing a workflow system in accordance withone embodiment of the invention;

FIG. 3 is a block diagram showing a task logic portion in accordancewith one embodiment of the invention;

FIG. 4 is a table showing task definitions in accordance with oneembodiment of the invention;

FIG. 5 is a table showing a rules logic portion in accordance with oneembodiment of the invention;

FIG. 6 is a diagram showing aspects of owner/beneficiary logic;

FIG. 7 is a diagram showing aspects of owner/beneficiary logic inaccordance with one embodiment of the invention;

FIG. 8 is a diagram showing a customer profile-interaction portion inaccordance with one embodiment of the invention;

FIG. 9 is a diagram showing a business coordinator portion in accordancewith one embodiment of the invention;

FIG. 10 is a diagram showing further aspects of operation of theworkflow system and the business coordinator portion in accordance withone embodiment of the invention;

FIG. 11 is a diagram showing yet further aspects of operation of theworkflow system and the business coordinator portion in accordance withone embodiment of the invention;

FIG. 12 is a block diagram showing details of the generalized imagesystem in accordance with one embodiment of the invention.

FIG. 13 is a block diagram showing an image system in accordance withone embodiment of the invention; and

FIG. 14 is a flowchart showing the process of retrieving an image inaccordance with one embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

Hereinafter, aspects of a workflow system in accordance with variousembodiments of the invention will be described. As used herein, any termin the singular may be interpreted to be in the plural, andalternatively, any term in the plural may be interpreted to be in thesingular.

The foregoing description of various products, methods, or apparatus andtheir attendant disadvantages described in the in the “Background of theInvention” is in no way intended to limit the scope of the invention, orto imply that the invention does not include some or all of the variouselements of known products, methods, and/or apparatus in one form oranother. Indeed, various embodiments of the invention may be capable ofovercoming some of the disadvantages of known products, methods, andapparatus while still retaining some or all of the various elements ofknown products, methods, and apparatus in one form or another.

The systems and methods of the invention provide the technical effect ofproviding the automated processing of a financial application andenhanced ability to access images associated with that processing.

The systems and methods of the invention are directed to what might becharacterized as an automated end-to-end case workflow system 100. FIG.1 is a block diagram showing the workflow system 10 in conjunction witha workflow process 20 in accordance with one embodiment of theinvention. That is, the workflow system 10 is used to perform theworkflow process 20. Specifically, the workflow system 10 provides thevarious tools to perform the workflow processing 20. Illustratively, theworkflow process might be used for processing an application.

In accordance with one embodiment of the invention, the workflowprocessing 20 involves three primary steps, as described further below.As shown in FIG. 1, a first step in the workflow processing is theperform underwriting loop 22. Then, the process passes to the performissue loop 24. After step 42, the process passes to step 26.

In step 26, the process of FIG. 1 performs a perform settlement loop 26.After step 26, the process passes to step 28. In step 28, the processfor the particular application, or other financial product for example,ends. In accordance with one aspect of the invention, the loops(22,24,26) of FIG. 1 are each respectively performed until theparticular loop is successfully completed. Accordingly, if some event orthe introduction of some document, for example, occurs, such occurrencemay re-start processing in a particular loop.

The invention provides an automated system that can incorporateinterfaces to multiple systems, including underwriting engines, andprovide the automated movement of a case through the process ofgenerating an insurance contract. The end-to-end case workflow system 10purpose is to provide this functionality without human intervention inprocessing a substantial portion of cases. However, there are times whenhuman intervention is required. Based on business rules and logic thesystem will present the case to the user for the required action. Oncethe required action is completed the case resumes automated processing.Various aspects of this processing are described below.

It should be appreciated that the present invention may be used inconjunction with various other known technology. In particular, thepresent invention may be used in conjunction with the teachings of U.S.patent application Ser. No. 10/777,634 filed Feb. 13, 2004 (AttorneyDocket Number 52493.000368) entitled METHOD AND SYSTEM FORELECTRONICALLY ROUTING AND PROCESSING INFORMATION, which is incorporatedherein by reference in its entirety. The Ser. No. 10/777,634 applicationis directed to a system for efficiently processing informationoriginating from documents having various sources, types and formats,and more specifically to a method and system for facilitating documentcollection, analyses and processing functions associated with aninsurance application process.

In accordance with one embodiment of the invention, the invention may bedescribed as including a variety of processing portions. FIG. 2 is ablock diagram showing the workflow system 10 in further detail. Theprocessing portions of the workflow system 10 include a workflow loopingportion 100, a task logic portion 200, a case management portion 300, arules logic portion 400, and a profile portion 500, as illustrated inFIG. 1. In accordance with some embodiments of the invention, theworkflow system 10 may further include a business coordinator portion600 and a generalized image system 700.

The workflow system 10 also includes a general processing portion 12.The general processing portion 12 handles various miscellaneousprocessing, not otherwise performed by the workflow system 10, so as toeffect operation of the workflow system 10. As shown in FIG. 2, theworkflow system 10 includes an interface portion 14. The interfaceportion 14 provides for interfacing with items and/or systems externalto the workflow system 10. For example, the interface portion 14provides for interfacing with user interfaces (16, 16′), as well asexternal systems (17,17′ and 18). As shown in FIG. 2, the interfaceportion 14 is used to input application information 15 regarding aparticular application, for example.

In addition, the workflow system 10 includes a general memory portion19. The general memory portion 19 provides for a wide variety of datastorage in practice of the invention. Accordingly, the general memoryportion 19 may be used by the various operating portions describedherein as may be desired. For example, the general memory portion 19might hold the rules set used to practice the systems and methods of theinvention.

Hereinafter, various aspects of these respective processing portionswill be described in detail. In accordance with the embodiment of FIG.2, the workflow system 10 includes a workflow looping portion 100.

Once the initial insurance application is data entered, the workflowsystem 10 begins the processing of a case. The workflow system 10, andspecifically the workflow looping portion 100, attempts to step throughthe workflow process as described herein. At each step the workflowsystem 10 will either succeed and move to the next step, hit a conditionthat requires human intervention and generate a task for a person, orsit in a wait state for more information to be provided from an externalsource. The workflow looping portion 100 controls the progressionthrough these steps, as well as the handling of wait states in thesteps, for example.

At a high level, the workflow system 10 processing workflow has threekey areas as noted above. These include the underwriting loop (aniterative, multi-day loop), the issue loop (a 1 day or else loop); and asettlement loop (a 1 day or else loop).

The underwriting loop 22 is the set of business steps or processesnecessary to fully underwrite a case and determine the appropriate riskclassification and rate class for a case. This loop is very muchiterative, due, in particular to new documents arriving that affect thecase. As a result the underwriting loop begins again upon a new documentarriving that effects the processing of the particular application.

The issue loop 24 is the loop that takes a fully underwritten case andultimately generates the printed policy to issue to the potentialpolicyholder. All of the steps in this loop must occur within the samecalendar day, or the entire process must occur the next workflow systemday, in accordance with one embodiment of the invention.

The settlement loop 26 is the loop that takes a fully underwritten andissued case and ultimately places the application/case in force with theappropriate administrative system. All of the steps in this loop mustoccur within the same calendar day, or the entire process must occur thenext workflow system day, in accordance with one embodiment of theinvention.

In accordance with one embodiment of the invention, the workflow system10 utilizes what is herein referred to as “wait states.” Wait states areprocess steps that allow a case to sit dormant while it waits for someevent to happen or piece of information to arrive. When a case is in await state, a case trigger is the notification to workflow system 10that an external event has occurred related to a given case, and thatcase needs to attempt to continue down its automatic path. In accordancewith one embodiment of the invention, the workflow looping portion 100may include a wait state portion 110 that controls operation of thevarious wait states as described herein.

In accordance with one embodiment of the invention, there are variouswait states. In particular, wait states may include (1) validate forunderwriting, (2) issue entry, and (3) settlement entry. In the validatefor underwriting wait state, the case cannot move ahead in the processbecause insufficient information is available to attempt to underwritethe case.

A further wait state is the issue entry wait state. In this wait state,the case cannot yet issue because of pending case management relateddocuments or tasks that need to be handled first. This may be true eventhough underwriting is complete.

Further, a “settlement entry” wait state may be utilized. In this waitstate, the case cannot yet settle, and go in force because pending casemanagement, legal or administrative needs that must be handled first. Asmay be appreciated, various other wait states may be added and used, asmay be desired.

In accordance with one embodiment of the invention, the workflow system10 further includes a task logic portion 200, as shown in FIG. 2. Thetask logic portion 200 is utilized in the situation when the workflowsystem 10 requires a human person to perform a particular taskassociated with the processing of the workflow system 10. That is, whenthe workflow system 10 needs a person to do work, the workflow system 10needs to create a task for the appropriate person or role. FIG. 3 is ablock diagram showing aspects of the task logic portion 200.

In accordance with one embodiment of the invention, the workflow system10 uses a task definition processing 210. In illustration of the taskdefinitions, FIG. 4 is a table listing particular task definitionsvis-à-vis either a case or a document.

As reflected in FIG. 4, cases are used in the processing of the workflowsystem 10, as well as documents. More specifically, a particular taskmay be associated with a case in general, as opposed to a particulardocument used in the processing of that case. On the other hand, thetask may well be associated with a particular document. An example ofprocessing required for a case, as opposed to a document, is that a caseneeds to have the rate class assigned in order to be validated by anunderwriter.

FIG. 4 shows that a first category of task is “discrepancy.” In thissituation, there is an actual problem with the case or document thatabsolutely requires human intervention. For example, the case ordocument may be bad, malformed or missing data as an example. Such adeficiency might be associated with the entire case, e.g. the entireinsurance application, and/or associated with a single document used inthe processing of that case. For example, a discrepancy is present if anapplication is missing the amount of coverage applied for or the date ofbirth provided has been scratched through to the point that it isunreadable.

A further category of task is a review task. This task used in theprocessing of the workflow system 10 mandates that a person shouldreview the case and/or the document to determine if any action isrequired. If no action is indeed required, the workflow system 10 thencloses the task out and allows the case to move on. For example, a“review task” might include review scuba diving activities to determineif there is any increased risk and therefore an increase in premium.

A further category of task is a verify task. A verify task is associatedwith a particular document. The verify task is associated with theowning role of an application versus a non-owning role. That is, averify task is given to the owning role of a document, when a non-owningrole changes a key document in important places. For example, themedical portion of an application might be the subject of a “verifytask.” Underwriters own this application part 2, yet exception managersmay update information that underwriters care about. Accordingly,further to a change by an exception manager, the particular changedinformation may be associated with a “verify task”, i.e., tagged so asto require review by an underwriter person. For example, a form might bemissing the reason for the last visit to the personal care provider. Thecompany requests this information from the applicant and the exceptionmanager enters the data provided into the data collector. Due to thischange in information the underwriter is alerted so that they can makethe appropriate risk assessment.

A further aspect of processing of the workflow system 10 is taskrevalidation (or what may be also referred to as “form validation”processing 220). Form validation processing relates to the task types ofFIG. 4 and the underwriting loop described herein. In accordance withone embodiment of the invention, whenever a data enterable document ischanged or added to a particular case, a process occurs related to thatcase, i.e., the form validation process.

The primary purpose for form validation is to scrub the appropriatedocument or documents to insure clean data. Related to tasks however,whenever an form validation is about to occur, the workflow system 10assumes that all task related to that document(s), and the case as awhole are resolved. Accordingly, tasks associated with that particulardocument are wiped clean. During the form validation processing thedocument is again checked for various deficiencies. If the samediscrepancies (or new ones) are found, then associated tasks areregenerated for people to work.

In association with the various features described herein, the workflowsystem 10 further provides includes “get work” processing 230, ascharacterized herein, in accordance with one embodiment of theinvention. The get work processing alerts a user to cases or particulartasks that have been assigned to the user. As used herein, “work item”means a case, task or other item that requires a user to process.

The get work processing to handle work items is handled by the tasklogic portion 200. Using a suitable user interface, a user may select a“get work” button. Upon the user selecting the “get work” button, theworkflow system 10 looks in the workflow system 10 for work itemsassociated with that particular user. This looking may be performedbased upon user identification criteria, user role, and/or whether aparticular case is assigned to the user. Further, the associationbetween a user and work items for that user may be tied to task types,team assignments, and/or other business conditions. For example, anexception manager would only receive cases that have tasks deemed to beones that an exception manager can address.

In addition to, or in alternative to, the “get work” processingdescribed above, the workflow system 10 may also use what is hereincharacterized as “queue based” assignment of work items 240, such astasks or assignments. In using queue based processing, the workflowsystem 10 generates information regarding a particular work item. Thiswork item information is then placed into a queue associated with aparticular user. The user may then access his or her queue to checkwhich work items have been assigned to them.

In accordance with another aspect of the invention, the workflow system10 of FIG. 2 also includes a case management portion 300. The casemanagement portion 300 controls the routing of cases to the appropriatecase management/underwriting systems. This routing can happen at anysuitable time in the process. For example, such routing can happen atdocument arrival or after data entry and processing of documentinformation.

To explain further, the workflow system 10 of FIG. 1 (and as describedherein) may interface with or include further systems (17, 18) that areused in the processing of cases, e.g., insurance applications. Suchfurther systems may, for example, be specialized systems that performspecialized processing associated with the processing of an application.Any number of further, specialized systems might be used based onproduct line factors, for example, or other factors.

The case management portion 300 controls the routing of cases to thesevarious systems that may be included in or interface with the workflowsystem 10. Further, the case management portion 300, in accordance withone embodiment of the invention, monitors the processing of cases in andby these specialized systems so as to obtain and retain statusinformation about a particular case. Accordingly, the workflow system 10provides across systems case status viewing allowing people and systemsto determine basic case status from one place, i.e., from one system toanother. Further, in accordance with one embodiment of the invention, auser may manually transfer a case from one system to another system ifsuch is desired. This might occur in the situation where it is manuallydetermined that processing by a particular system is not required, butprocessing by another system is required.

As processing of a case in the workflow system 10 is completed, the casemanagement portion 300 may output the case to an appropriateadministration system. That is, the workflow system 10, as describedherein, provides the ability to fully process a case up throughunderwriting and issuance, to the point of placing the case in-force. Atsuch time, the case management portion 300 automatically sends the caseto chosen administrative system. Thereafter, the administrative systemmaintains the case through its life.

The workflow system 10 performs a wide variety of processing for aparticular case, e.g., insurance application. In particular, theworkflow system 10 can successfully process a life insurance applicationwithout human intervention due largely to its ability to perform actionsupon a case. These actions are coded as “rules” in a massive rules“engine”. In accordance with one embodiment of the invention, theserules that are used in the processing of the workflow system 10 areimplemented by the rules logic portion 400. That is, as shown in FIG. 5,the rules logic portion 400 includes a rules engine 402. Using theserules, the workflow system 10 effectively replicates actions anddecisions that a human processor would have made, thereby removing thehuman user from the process for the most part. For example, it is notedthat some of the most difficult decisions concern the proper wording ofowner and beneficiary designations and the handling of replacementpolicies to comply with complex state regulations. These regulationstypically vary by state.

Hereinafter, further aspects of the rules logic of the workflow system10 will be described relating to owner/beneficiary wording logic.Processing of owner/beneficiary wording logic is performed by theowner-beneficiary logic portion 410 in the rules logic portion 400, asshown in FIG. 5. It is fully appreciated that proper designation of anowner and beneficiary on a life insurance policy is absolutely crucial,for obvious reasons. This information is of course collected from theowner of the policy, for example, at some point in the processing of theworkflow system 10, and typically, in initial processing, as would beexpected. In accordance with one embodiment of the invention, theworkflow system 10 uses a form to collect owner/beneficiary information,in conjunction with the collection of other information. In particular,such information may be solicited in a free-text box. Consequently,applicants submit this information in a variety of formats and varyingdegrees of accuracy.

To effect data entry of such owner/beneficiary logic, systems werepreviously used (prior to the present invention) in which a data entryoperator (DEO) selected what they believed to be a correct “template.”The data entry operator would then interpret the application informationto ensure that the application information was entered in an accurateand legally-acceptable rendering. FIG. 6 is illustrative of this priorprocessing. In development of the present invention, analysis of pastcases showed a significant error rate in this translation performed bythe data entry operator.

In contrast to this prior processing, the present workflow system 10removes need for interpretation by the data entry operator. Inparticular, the present invention addresses the fact that there arevarious owner/beneficiary designations, and associated therewith, aremultiple acceptable formats for the various designations. Suchprocessing is performed by the owner-beneficiary logic portion 410 inthe workflow system 10.

The owner-beneficiary logic portion 410 contains a series of templatesfor each type of designation, i.e., such as individual, trust, orestate, for example. In operation, the owner-beneficiary logic portion410 prompts the data entry operator to enter some basic informationabout the TYPE of owner or beneficiary. The owner-beneficiary logicportion 410 then progressively walks the data entry operator through thecorrect template (which the owner-beneficiary logic portion 410 selectedbased on the basic information. This correct template contains theproper “fixed” wording for the corresponding designation and solicitsthe Data Entry Operator for the “variable” wording only. Missing orconflicting information is identified by the owner-beneficiary logicportion 410 and is handled as a “requirement” without the need for humanintervention. FIG. 7 is a flowchart showing aspects of this processingperformed by the owner-beneficiary logic portion 410.

The result of the processing of the owner-beneficiary logic portion 410is a legally acceptable, fully compliant designation for owners andbeneficiaries which has substantially reduced error rates and virtuallyeliminates interpretation by data entry operator. As illustrated above,this information is output to suitable processing system, either withinor interfaced with the workflow system 10 that all necessarycorrespondence is properly populated.

In accordance with one embodiment of the invention, the rules logicportion 400 also includes a replacement logic portion 420. Inexplanation of the replacement logic portion 420, it is appreciated thatone of the more complicated facets of life insurance processing is thecorrect handling of applications that are to replace existing insurance.In the processing of insurance applications, over half of such businessmay fall into the area of replacing existing insurance. This includesthe replacement of existing company policies for another company policy(internal replacement) as well as the replacement of other companies'policies with a new company policy (external replacement).

States may follow an applicable “replacement protocol.” For example,many states follow the NAIC replacement model. However, many statesstill maintain separate requirements, each of which must be met withinan allowable timeframe in processing of a replacement application. Thatis, because insurance is still regulated at the state level, each stateinsurance commission requires somewhat different handling of replacementpolicies. The result is a complex and convoluted mix of tediousregulations requiring substantial processing effort.

In accordance with one embodiment of the invention, the workflow system10 successfully codifies most replacement processing and takes intoaccount all various state regulations. This complex code solicits inputsfrom the data collectors and runs rules against that data to ascertainthe type of replacement indicated. Based on the “type” of replacement,the system identifies specific state requirements by referencing aseries of multi-level, or “3-D” tables. These user-maintained tablesprovide the system with the latest replacement regulations for eachstate. The rules engine 402 then automatically processes thisinformation and takes the necessary workflow actions. Based on thereplacement type, the workflow system 10 automatically sends, forexample, Replacement Co-notices and policy summaries (when required)within the state-dictated timeframes. Additional actions include thesetting of a “nag clock” to ensure that required documentation isreceived within the allotted time and automatic follow-up for missinginformation. This automation significantly reduces an insurancecompany's exposure to compliance violations by ensuring the timely andaccurate processing of this information and is a key element in theworkflow system 10's ability to process a case touch-free, in accordancewith one embodiment of the invention.

In accordance with one embodiment of the invention, the workflow system10 further includes a customer profile-interaction portion 500, shown infurther detail in Fig. The customer profile-interaction portion 500enhances the ability of the workflow system 10 to interact withcustomers automatically. That is, as the workflow system 10 effects theprocess of FIG. 1, the workflow system 10 interacts with the customerautomatically.

To explain, it should be appreciated that an insurance business may wellbe built over the years on personal relationships. The workflow system10, while attempting to standardize and automate processing as much aspossible, is also flexible enough to accommodate specific customerpreferences. The customer profile-interaction portion 500 includes orinterfaces with a customer profile portion 510 that contains a profileof each customer. This profile specifies each customer's specificprocessing preferences. These processing preferences might includecontact information, email address, preferred method of communication,frequency of communication, channel code, types of communicationsdesired, mailing preferences, preferred nag intervals, as well as otherparameters associated with customer contact.

In the processing of workflow system 10, the workflow system 10 willfrom time to time need to interact with a customer. This situationtriggers operation of the customer profile-interaction portion 500.Specifically, the customer profile-interaction portion 500 is accessedby the workflow system 10 to retrieve information regarding how and whenthat interaction with a customer should occur. The customer profiles inthe customer profile portion 510 are fully editable and maintainable bysuitable persons, who may be given access as desired.

Described above are various aspects of operation of the workflow system10. The workflow system 10 may further include what is hereincharacterized as a business coordinator portion 600. The businesscoordinator portion 600, in particular, is included in the workflowsystem 10 to provide flexibility in coordinating, tracking, andprocessing as much of an insurance company's new business cases (e.g.,applications) as possible, immediately upon introduction. Also, when newinsurance products are introduced to the insurance company, immediate,yet limited, benefits need to be realized in automating the coordinationof these products. The business coordinator portion 600 assists in thisneeded processing of the workflow system 10.

In further explanation of the operation of the business coordinatorportion 600, in many insurance companies, different products requiredifferent business processes, and at least initially, different computerprocessing systems. Reasons for this include different insuranceregulations, company mergers and more. Requiring different computerprocessing systems poses an organizational nightmare in a company. Thisis especially true in trying to track different insurance requests inall of these systems. It is also difficult to match new documents andother information to the right applicants and applications whenapplications span all of these systems. Operation of the businesscoordinator portion 600 addresses these issues, and provides time tomerge processes and systems, if and when necessary. Accordingly, thebusiness coordinator portion 600 enhances operation of insurance andother financial services and products that require information frommultiple sources, and in financial industries where multiple newbusiness processing systems are commonplace.

In accordance with one embodiment of the invention, the businesscoordinator portion 600 includes a variety of portions that provide fora variety of features. As shown in FIG. 9, the business coordinatorportion 600 includes what is herein characterized as a shared servicesprocessing portion 610 and a coordinator internal processing portion620.

The shared services processing portion 610 provides for processing thatbenefits not only operation of the business coordinator portion 600, butalso operation of other processing in the workflow system 10.

For example, the shared services processing portion 610 includes adocument imaging portion 612, in accordance with one embodiment of theinvention. The document imaging portion 612 is a document imaging systemthat reduces manual paper handling of insurance requests. Further, thedocument imaging portion 612 provides for long term archival ofinformation. This processing benefits numerous processing portionsacross the workflow system 10 in that a document may be input andeffectively manipulated in the workflow system 10 using the documentimaging portion 612.

Further, the shared services processing portion 610 also includes anelectronic information receipt portion 614. The electronic informationreceipt portion 614 provides for the ability to receive informationelectronically, as well as through standard mail, packages, etc., forexample. Accordingly, the electronic information receipt portion 614allows for significant improvements in automation.

The shared services processing portion 610 further includes an indexingand matching portion 615. In accordance with one embodiment of theinvention, the indexing and matching portion 615 is important forcoordination between different processing portions in the workflowsystem 10. That is, as any information arrives that is intended for newbusiness processing, a key problem occurs in trying to identify thedocument type and the person/application that the information is relatedto. The problem is significant if separate new business systems handletheir indexing and matching on their own. Instead, the indexing andmatching portion 615 is in place to handle ALL indexing and matching forALL new business systems.

The shared services processing portion 610 further includes a data entryportion 616. The data entry portion 616 monitors entry of data into theworkflow system 10. As key information is associated with an insurancerequest or case, that information may need to be electronically ormanually ‘data entered’ in order for automatic business rules to processthat information. This ‘data entry’ can be useful for determining whichsystem a case needs to go to, and it can be useful for directly handlingthe case management and underwriting of the case, especially when thedesignated underwriting system is heavily automated.

As noted above, “key” information may be associated with an insurancerequest or case. That is, it is appreciated that various information maycome into the workflow system 10 in various manners, e.g.,electronically or a paper submission such as e-mails or phone calls. Inaccordance with one embodiment of the invention, such information isreviewed either electronically or by a person to determine if anyinformation in the submission is “key”, i.e., of sufficient importancesuch that the identified key information will be entered in the workflowsystem 10. Such key information may well affect processing of anapplication in one of the loops. For example, such information mightresult in the underwriting process, i.e., the loop, being started over.Accordingly, it is appreciated that of course not all information willbe entered into the workflow system 10 so as to affect processing of anapplication in the workflow system 10, i.e., information that does notaffect underwriting. This decisioning logic is based on the rules atwork in the workflow system 10.

As a further note, in accordance with one embodiment of the invention, aloop, e.g., the underwriting loop, once information such a document isinput into the workflow system 10, the loop may be fully restarted.Alternatively, a decision process may be implemented upon such newinformation coming into the workflow system 10. Based on this decisionprocess, the particular loop may be started over, or alternately, may bestarted at the point the loop was stopped upon identification of the newinformation. That is, it may be determined that (based on theinformation) there is no need to restart the particular loop, such asfor example the underwriting loop.

The shared services processing portion 610 further includes a casemanagement processing portion 618. The case management processingportion 618 coordinates operations between the workflow system 10 andother external systems in accordance with one embodiment of theinvention. That is, is it appreciated that there are a wide range ofcases, e.g., applications, with a correspondingly wide range ofprocessing requirements. A particular application, for example, may beable to be processed fully within the workflow system 10. Alternatively,a particular application may need to involve external processing. Thatis, if the coordinating system (the workflow system 10) is capable ofdirectly processing an insurance request, then there is no need toinvolve an external system at all. If however, an insurance requestcannot be fully processed directly by the workflow system 10, then thecase management processing portion 618 controls the handoff of theinsurance request to such external processing system and tracks theapplication's progress through the external system. It may be that theparticular application is processed by the external system and thenreturned to the workflow system 10 for further processing. Accordingly,in this situation, the case management processing portion 618coordinates the re-entry of the particular case into the workflow system10.

As noted above, the business coordinator portion 600 further includes acoordinator internal processing portion 620. The coordinator internalprocessing portion 620 effects further helpful processing.

In accordance with one embodiment of the invention, the coordinatorinternal processing portion 620 includes a configurable case routingportion 622. The configurable case routing portion 622 provides forconfigurable, characteristic driven routing of cases (or items relatedto cases) to appropriate case management/underwriting systems. Theconfigurable case routing portion 622 provides for decision-making,which might happen at document (or other type of information) arrival,and after data entry and/or interpretation of the information on thedocument itself. Illustratively, the configurable case routing portion622 operates upon receipt of the primary insurance application itself,where the application is for a product type that must be routed. Afurther illustrative example of the configurable case routing portion622 occurs in the condition where the requested face amount is beyondthe limits that have been set by the coordinating system, e.g., theworkflow system 10. As a result another system, possibly more manual innature must be engaged.

The coordinator internal processing portion 620 further includes asubmit pending portion 623. The submit pending portion 623 provides auser processing new business (a new business coordinator) with theability to send a new business application/case that has not yet beenunderwritten, i.e., a pending case, to another case management andunderwriting system. That is, it may be the situation that the newbusiness coordinator comes to identify a particular application thatshould not be processed by the workflow system 10. The submit pendingportion 623 provides the new business coordinator the ability totransfer that application to an external system, outside the workflowsystem 10, for processing, in accordance with one embodiment of theinvention.

The coordinator internal processing portion 620 further includes asubmit issued portion 623. The submit issued portion 623 provides a newbusiness coordinator with the ability to send a case that has been fullyunderwritten and issued to another system that can complete the finalprocessing of the case to include placing the case “in-Force.”

Further, the coordinator internal processing portion 620 includes asubmit in-force portion 626. The submit in-force portion 626 provides anew business coordinator the ability to send a case that has been fullyunderwritten, issued, and settled to a policy administration system forpolicy management.

Further, the coordinator internal processing portion 620 includes a caseescape portion 627. The case escape portion 627 provides the ability fora user to manually route a case or application, for example, to anothernew business system. This ability is especially important when a newproduct is introduced, a new system is in its infancy, or business rulesand processes are in need of change.

Further, the coordinator internal processing portion 620 includes a casetracking portion 628. The case tracking portion 628 is a processingportion that provides the ability to see the status and basicinformation about a case/application directly from the workflow system10. This is true regardless of what new business system is trulyprocessing the case at that time. In operation, the case trackingportion 628 performs its processing in various ways. In accordance withone embodiment of the invention, the case tracking portion 628 in theworkflow system 10 regularly monitors the other new business systems orother external systems for status, as well as monitors the status ofcases in the workflow system 10. In order to allow the case trackingportion 628, the new business systems themselves need to provide regularupdates to the coordinator. Alternatively, the case tracking portion 628is provided with real time access to obtain status information from theother new business systems.

Further to the discussion above, FIG. 10 and FIG. 11 show additionalaspects of the operation of the workflow system 10, and in particularoperation of the business coordinator portion 600.

In further explanation, FIG. 10 is a high level case flow, in accordancewith one embodiment of the invention. This diagram shows high level caseflow through a new business system for a common application case. Asshown, the process starts with the underwriter loop on the left,beginning at the Assign Initial Rate Class workflow step.

Other than Assign Initial Rate Class (AIRC), the other steps shown arekey workflow steps where cases can remain in a wait state for asignificant period of time. AIRC is the first step for a case, inaccordance with one embodiment of the invention.

Whenever a document arrives and is validated for a case, that case (mostof the time) gets sent back to the very beginning of the underwritingloop. This is constantly true for a case, until the case goes toapproved hold. At that point, the case is considered ‘frozen’ from adata and underwriting point of view, in accordance with one embodimentof the invention.

In accordance with further aspects of the invention, FIG. 11 shows highlevel case flow showing exit points. That is, FIG. 11 shows high levelcase flow through a new business system, and shows the different placeswhere a case, i.e., an application for example, could leave thecoordinating system, to arrive at another new business system forprocessing.

In addition to these outputs, the coordinating system also fetches orreceives constant case statuses or updates in order to provide acomprehensive view of case statuses throughout new business processing.Accordingly, FIG. 11 shows that the workflow system 10 may be used withvarious other processing systems in the processing of a particularapplication.

Hereinafter, further aspects of the present inventions will be describedwith regard to the processing of images in the workflow system 10. Asshould be appreciated, a wide variety of images are used in operation ofthe workflow system 10. As shown in FIG. 2, the workflow system 10includes a generalized image system 700, in accordance with oneembodiment of the invention.

The generalized image system 700 is used to isolate users of a criticalsystem process from the underlying image storage and retrieval processtypically handled directly between a client and the server. Byperforming this processing, the workflow system 10 is provided with amore flexible system where a user is unaware of the underlyingimplementation. Accordingly, making changes or bridging gaps betweensystems and their implementation can be done seamlessly to the users.The generalized image system 700 as described below, further providesthe ability to distribute information to different localities and accessthe data even when the underlying system may be down, i.e., such as forregular or emergency maintenance.

In development of the generalized image system 700, various needs may beaddressed. In accordance with one aspect of the invention, a first needis to be able to interface different image systems. For example, acompany might generate a newly written custom business application whichis interfaced with an underlying image system. Further, it might be thesituation that the underlying image system is anticipated to be replacedin some short period of time. In such a situation, it may be desired toinsure that the image interface layer (between the new and old systems)is focused enough to meet all the business viewing and retrieval needsand yet extensible enough to make swapping out the underlying imagesystem trivial and transparent to the end users and backend processes.

Relatedly, a further potential need may be focused around a situationwhere few clients are capable of displaying the image format generatedas a result of scanning. The generalized image system 700 allows thetranslation of a variety of image formats being stored into a singleoutput format so that a common viewer may be used to display the imagecontent to the users. This arrangement de-couples the various users fromthe input format and allows for a controlled output format to be used.

A third need may revolve around physical locality. In operation of acompany, for example, a portion of the work may be done at distantfacilities, eg an offshore facility. Users at these distant facultiesneed to view documents in the workflow system 10 in the normal businessroutine. Due to the size of these images it may be a better performanceoption to distribute a subset of images that these users would need intheir own geographic location. Relatedly, a storage solution may beprovided that could store locally a subset of images. Furthermore, it isappreciated that an offshore group may work during hours when aparticular system is down for nightly backup, yet they still neededaccess to the images.

A fourth need addressed by the generalized image system 700 describedherein is the need to develop a bridge between the business workflowsystem developed and the images necessary to perform the work. Thisbridge may require the detection of new images and the mapping of theseinto a system which would understand how to route them to theappropriate work.

A fifth need addressed by the generalized image system 700 relates to asituation where there is a time period where both a local system and anoffshore system is active at the same time. This requires an imagesystem which is capable of abstracting to a level where the requestingprocesses do not know or care about which of these underlying system maycontain the content being requested.

Hereinafter, various terminology will be described below so as to assistin the description of the generalized image system 700. An image may beconsidered to be both the content in an image and the properties aboutthe image vital to display. This may include such things as the imagesystem, a native identifier in that system, number of pages in theimage, etc. for example. Images may also be referred to as documents.

An image system, such as the image system 700, means a system thathandles the storage and retrieval of images. Such a system providesindefinite archiving capabilities for these images (limited only byspace—and often allowing for removable, swappable mediums thuseliminating these space limitations). These systems may also provideother interfaces for scanning and otherwise committing new documents.

In accordance with one embodiment of the invention the generalized imagesystem 700 in essence abstracts an image system without implementing theunderlying long-term archival capabilities and without providing anykind of scanner or committal interface usually associated with such asystem.

An image format may be understood to mean how the image is wrapped upand compressed for storage. A variety of different compression formatsand wrappers can be used by any given image system. It is appreciatedthat in practice of the invention, the image format must be understoodto be able to turn the image back into something that is displayable.

The generalized image system 700 responds to image requests. A clientmay request all or part of an image's content or its properties,depending on the need. Image requests may fall into one of two differentmethods of access. As described below, an image may be requesteddirectly from the generalized image system via a “bean,” or are accessedfrom the generalized image system via HTTP (the protocol web browsersuse).

As used herein, a cache is a repository for information about an image.The cache can contain an arbitrary number of items, limited only bystorage space. Items in a cache can be accessed without referring to theoriginal image system at all. As a verb, cache may refer to the actionof committing or writing items into a cache repository.

A workflow system is a system which provides the necessary businesslogic to take a task and move the task from beginning to end. Forexample, a workflow system may include logic whereby a document is movedfrom indexing through to the policy issue phase.

Further, a poller process is a process where-by one is able toperiodically search for items in one system and take action on thoseitems which are found. In the scope of the current implementation such aprocess may be used to find new documents and introduce the newdocuments into a workflow system.

The generalized image system 700 as described herein provides a varietyof features and benefits associated with those features. FIG. 12 listsvarious benefits of the generalized image system 700. Further, FIG. 13is a block diagram showing the architecture of the generalized imagesystem 700 in accordance with one embodiment of the invention. FIG. 13shows various processing portions that may be used in the practice ofthe image system, in accordance with one embodiment of the invention.This system is described in detail below. As shown by the arrows in FIG.13, various components communicate or interface with other components.

In accordance with one aspect of the invention, the generalized imagesystem 700 abstracts an underlying image system and providescapabilities to provide common interface for systems, i.e., for viewingby a user. To explain, the generalized image system 700 provides acommon abstraction layer over the typical image system functionalitynecessary for a client o retrieve information. By developing this layerof abstraction it is possible to provide a common interface and developclients around a known architecture without worrying about how thingsmay change in the future, or even what image system or systems may beproviding your content. As a result one can build a variety of clientsto interface with this abstract layer and changing the underlying systemonly requires updates in a centralized area, i.e., the centralized areaof the change. Once one has completed writing the necessary code to plugthe new system into the abstraction layer, all the other clients will beable to interface with it immediately.

Further, it should be appreciated that the capability provided by thegeneralized image system 700 as described herein goes beyond the otherclients not having to do work to interface with a new system. That is,other clients and systems accessing images actually remain unaware thatthere has even been a system change or a new system. They are treatingthe abstraction layer as their image system and the fact that theunderlying image systems have changed is never translated up to a layerwhere they become aware.

The generalized image system 700 also adds diverse geographic cachingabilities to any image system. To explain, it should be noted that animage system may not have functionality built in to be able to replicatetheir data to different machines or different locations. The generalizedimage system 700 adds this capability to any image system that itabstracts. Caching can be done in various ways (configurable at run-timeby a suitable set of parameters), in accordance with one embodiment ofthe invention. A peer cache will contain all the images sent to itsmaster. At some level you must supply a main cache; however if youimplement cache triggering at the poller level, you may actually have avariety of different main caches for each poller purpose. In this senseyou may take any set of images and distribute them among sites inwhatever manner is needed.

In accordance with one embodiment of the invention, the generalizedimage system 700 also provides for independent cache subsets which maybe specified. When a request is made to a server running a cache managerservice, using the invention, one may choose to push only certain imagesto another set of servers. Typically these images are a subset of themain cache. However, it is appreciated that any desired image my bepushed to a further server or a set of servers.

In short, the generalized image system 700 allows a user to establish anappropriate configuration as desired. Accordingly, the generalized imagesystem 700 allows a user, by suitably configuring the generalized imagesystem 700, to cache any set of images in any location that the userneeds such images. That is, in accordance with one embodiment of theinvention, one only needs to provide a poller process to initiate cacherequests to the appropriate cache managers, i.e., some controllingprocess needs to be provided to effect a polling process and theinteraction of such with respective caches.

The generalized image system 700 further provides for translation ofrequested formats on the fly for viewing by the requesting user. As isappreciated, the decoding and encoding of image formats is not a newconcept. Further, it is noted that in order to develop a viable imageformat one must provide methods for doing both coding and decoding.Further, the decoding will generally be public knowledge.

However, above and beyond known coding and decoding, the generalizedimage system 700 of the invention provides functionality to translatefrom one format to another during the retrieval process. This abilityenables the client to expect a particular format and access/view thegeneralized image system 700 as though the generalized image system 700only presents in that particular format. This can greatly ease theimplementation of a client since one does not have to worry about whatimage formats may be used in the system. The generalized image system700 also abstracts images retrieved from storage, in accordance with oneembodiment of the invention. Accordingly, should the format of thestored image be changed, the client doesn't need to know (or bere-developed) to address the change in the underlying image.

It is appreciated that known of-the-shelf products may be used toperform the image decoding and encoding in the generalized image system700. For example, SnowBound's RasterMaster may be used. However, it isappreciated that the decoding/encoding software might be viewed simplyas an enabling piece. Accordingly, various other products might be usedto effect the encoding and decoding, or a custom written set of imagedecoding/encoding utilities might be utilized. Accordingly, theinvention provides a coding/decoding system in an image system tonormalize the output of the image system.

The generalized image system 700 may further be used to create a bridgebetween an image system(s) and a business workflow system. To explain, apoller process is a means by which one may create a bridge between twodifferent systems. The image system specifically makes it possible via aset of functions to create a poller process which can translate theincoming set of documents into a useful business workflow system.

Without such a feature each system interfacing with the image systemwould need to implement all the functionality necessary to retrieve workdirectly and then create appropriate tasks. With the abstraction layercreating a polling interface which is independent of the underlyingimage system it is possible to do this from a centralized place.

This abstraction layer also makes it possible to change to another imagesystem, or even add an additional image system(s) to feed into the sameworkflow. With this ability sources may be added, taken away, or changedwithout any modification to the particular workflow system.

The generalized image system 700 further allows for multiple imagesystems to be accessed from a single process. As mentioned, it ispossible for the system to support multiple image systems at the sametime. Since the generalized image system provides its own identifiersfor use by the client, there is no direct tie from client to theunderlying image system.

All translation and content retrieval is done internal to thegeneralized image system. Because of this it is possible to have aclient pull data from a variety of enabled sources without worryingabout which system contains the needed data. Clients simply make arequest and the appropriate image is retrieved from whatever systemcontains the content. Clients don't need to be written to understandseveral systems or have any kind of fallback retrieval order—they canjust worry about interfacing with the generalized system.

Further, the generalized image system 700 allows for new image systemsto be plugged into existing architecture, transparent to the clientsystems. It is possible to create a new plug-in into the existingarchitecture to enable a completely new kind of image server, withoutany client modification to begin retrieving the new system's content.All the necessary changes are internal to the abstraction layer tosupport a new system. Clients continue to access their content the sameway, and receive the same results, before and after the new system isadded. Content from the new system will also continue to be presented inthe same way as content from the other enabled systems.

Further, the generalized image system 700 allows for multiple types ofclients to access all available data (since data that client may not beable to understand is translated into its native format). Since thegeneralized image system 700 provides the ability to normalize theoutput to a known format, it is possible to change to a format that anygiven client can understand. This means that one can choose any viewerthat best meets business needs, or even create a custom viewer, andnormalize the output for compatibility with that viewer.

It is further enabled by the generalized image system 700 to createmultiple access routes into the system, so that one can have a varietyof viewers each accessing the system and receiving data in their nativeformat. This gives businesses the flexibility to select viewing clientson what best meets their business needs and not worry about the formats.A good example of this is PDF. Acrobat reader is a popular viewer andmany understand its feature set well. If we desire to use Acrobat, wesimply translate all output data to PDF. At the same time we can utilizea custom viewer which provides functionality tailored to our business toview the same content.

Further, the generalized image system 700 allows for access of some dataeven when image system is down, i.e., provided that the data to beaccessed is cached. It is provided for to take images as they come intothe system and cache them to the local or other servers. The generalizedimage system is configurable on how it reads data from cache, so thatone may specify a number of caches to check before falling back on theunderlying image system for retrieval. In accordance with one embodimentof the invention, if an image is cached then the underlying image systemis never accessed. This means that even if an image system is down (sayfor nightly maintenance) then the users will be able to retrieve andview their required content.

Assuming that you can do a good job of identifying the images that yourusers are going to need ahead of time, it is possible to reduce a largepercentage or perhaps even all access directly back to the image system.In such a scenario the only access to the image system might be from thepolling process, for example. There may be a number of business issuesand emergency outages that result in the unavailability of the imagesystem itself. Further, in development of the present invention, it isestimated that over 80% of images viewed by most users may be identifiedand cached. By caching these required images, the system maintains theappearance of being available even if the underlying image system ishaving an outage, for example.

A further capability of the generalized image system 700 is that thesystem can run on independent architectures. The image system might bewritten in JAVA (a common programming language), utilizing the J2EEstandard (JAVA service provider requirements). These standards arecapable of running on a variety of architectures, including Linux,Windows, HP-UX, AIX, and Solaris. As a result we are not tied to anyparticular system for running this image system. The generalized imagesystem can in-fact be run on a completely different platform than theunderlying image system requires. This enables us to select the platformwe want to have for client and other system access based on our cost andstability needs.

Further, the workflow looping portion 100 may be used to distributesnetwork load. caching provides the system with the ability to distributeimages to different locations, so that the clients in that location donot have to leave their local network. This provides enhancedperformance and reduces the overall network load.

The generalized image system 700 further provides the ability to cacheimages to a remote location, and then have that remote location pass onimages to caches in other locations. This gives the system furtherflexibility to control how images are distributed from cache to cache. Aproperly configured cache system can significantly reduce the amount ofnetwork traffic required from site to site.

Hereinafter, an illustrative example is set forth regarding operation ofthe generalized image system 700. Specifically, a walk-through of anexample scenario is provided where the image system provides asuccessful abstraction of a complex process—to the point where the usershad literally no impact from the change. The example relates to changingout an underlying system.

In this example, a business had standardized on using Adobe Acrobat toview image content stored in the image system. At the time the decisionwas made to use Acrobat, image formats being used in the underlyingsystem (AWD), were MO:DCA, some TIFF, and ASCII text. By using thegeneralized image system, the users were able to set up an interfacewhich converted all these varying formats to PDF and allowed them to useAcrobat to pull up any image from their underlying image system, AWD.

After about a year the business decided for cost and overallfunctionality reasons to change out the AWD system and implement asystem based on FileNet IS. The change of the image system had thepotential to require every business application accessing the imagesystem to be re-written to support the new system. However, inimplementation of the invention, a module was written to provide thenecessary interface with FileNet. This interface was plugged into theimage system abstraction layer and a small amount of code written to beable to enable or disable the plugin at run-time. No code was changed inthe poller, the workflow system itself, or any of the viewer clients.

Further, in this example, part of the project involved the conversion ofall the data in the old image system (AWD) to the new image system(FileNet). We took these updated image pointers and updated the abstractimage system to point to the new images. At this time we also enabledthe FileNet system interface in the abstract image system.

Users were successfully able to pull both unconverted AWD images andFileNet images without noticing any service interruption or change intheir interface. As the conversion was completed the AWD system plug-inwas turned off in the generalized image system.

The workflow system was able to be converted to use FileNet withoutchanging any code in the Genius system or its poller interface toaccomplish the task. The system successfully abstracted the underlyingimplementation without any user interface change or interruption ofservice.

Hereinafter, various features of the generalized image system 700 willbe described with reference to FIG. 13. FIG. 13 is a block diagramshowing one embodiment of a generalized image system 1300 in furtherdetail, in accordance with one embodiment of the invention.

The generalized image system 1300 includes various components includingimage viewing clients (1302, 1304) and an image request handlingsubsystem 1310. The generalized image system 1300 further includes asystem cache manager 1330, an image format handling layer 1320, and ageneralized image system data map 1350. As described below, thegeneralized image system 1300 may utilize a poller process 1390, inaccordance with one embodiment of the invention.

Further, as shown in FIG. 13, the generalized image system 1300 includesmultiple image system plug-in adapters (1380′, 1380″, 1380′″) thatrespectively interface with underlying image systems 1370.

In accordance with one embodiment of the invention, an image viewingclient (1302, 1304) is any one or more programs designed to initiate arequest to the image request handling subsystem (1310) and displaydesired content. Any number of clients, such as ACROBAT READER, can bewrapped in a request mechanism designed to be able to retrieve thecontent and pass it back to a helper. In many cases the wrapper will beanother third party application such as INTERNET EXPLORER or MOZILLAwhich is capable of initiating a request to a server for content, thenpassing the content to the format handler.

The image viewing client (1302, 1304) may also be a custom writtenapplication which serves as both the rendering application and/or therequest application. In accordance with one embodiment of the invention,an applet has been designed as a component of the generalized imagesystem to serve as a rendering application (in conjunction with any webbrowser as a request application) should a third party application notbe desired.

The image request handling subsystem 1310 is a service provider whichwill retrieve and request conversion of the content and provide theappropriate data back to the image viewing client (1302, 1304). Eitherof two scenarios is possible when making an image request. (1) The imageis in system cache, or (2) the image is not available in cache. Inaccordance with one embodiment of the invention, the image requesthandler will use the following logic as illustrated by the flowchart ofFIG. 14 to retrieve content for transport to the image viewing client.

As shown in FIG. 14, the method starts in step 1400 and passes to step1410. In step 1410, the system cache manager (1330) is asked to checkits caches (any of the configured caches 1342, 1344, 1346) for therequested image. If an image and its associated meta-data is availablein one of the caches then the data is returned to the request handlingsubsystem. After step 1410 of FIG. 14, the method passes to step 1420.

In step 1420, if no data is returned from the system cache manager thena request is made to the generalized image adapter layer (1360) for theimage content. Aspects of the adapter layer 1360 and how content isretrieved using the adaptor layer are described below.

Then, in step 1430, if no content is returned from either system then anappropriate error message is returned to the client, indicating that theimage is either irretrievable or not an image in the system, whicheveris appropriate. After step 1430, the process passes to step 1440.

In step 1440, if content is available from either the call in (1410) or(1420), then the image format is checked against the format the viewingclient is requesting. If any format conversion needs to be done then thedata is sent to the image format handling layer (1320) for conversionand the appropriate content data is returned.

Then, in step 1450, the now appropriately formatted image data isreturned to the requesting client for rendering. After step 1450, theprocess passes to step 14660, and the process ends.

The system cache manager 1330 provides services for writing and readingcache data. The system cache manager 1330 also provides a configurableinterface (via runtime modifiable property files) for initiatingpass-through requests to other systems when a write request is received.

Hereinafter, aspects of writing data will be described in accordancewith one embodiment of the invention. The cache manager 1330 has twointerfaces for writing data into the system. The first is a publicinterface designed to initiate the cache request. Usually a pollerprocess (1390) or other such process (not shown) will use apre-determined algorithm to identify which images should be cached. Suchan algorithm is generally driven by logic specific to the needs of thebusiness using the system 1300.

The initiating process will send to the system cache manager a requestto cache a given image (on the generalized image system'sidentifiers—not to be confused with one of the underlying image system'sidentifiers), along with the type of the request (generally a main cacherequest or an independent cache request). The process may choose to sendthe data to the cache manager to preserve an additional lookup (forefficiency), or it may simply pass the ID and have the system cachemanager initiate the lookup itself.

Generally a single output format is desired for the image viewingclients (1302). To aid in quick processing of images the system cachemanager may be configured to request the image format handling layer(1320) to change the format to a pre-configured type before caching thedata. This makes the retrieval process of the image request handlingsubsystem (1310) more efficient since no image conversion is necessaryfor cached retrieval of this format type.

The second interface is a private interface whose behavior is defined bysystem configuration (via runtime modifiable property files). The systemcan be configured with a set of peer caches, which should contain allthe data sent to the main cache of the system (though a peer cache maybe fed by multiple main caches so it's not necessarily an exact mirrorof a particular main cache). When a request is sent to a systemconfigured with peer caches then the request will be automaticallypassed through to the other systems.

There is no limit to the number of peers. Peers may also have otherpeers. This provides an advantage when trying to control networktraffic. For example, let's say you have an initiating client on theeast coast and three server machines, one on the east coast and two onthe west coast, which you want to all contain certain cache data. Tominimize traffic one can set up west1 as a peer to east and west2 as apeer to west1. An image cache request to east will automatically triggera pass-through request to west1, which will in turn transmit anotherpass-through to west2. The data is now on all three servers, but it onlyhad to be transmitted from the east coast to west coast once.Appropriate configuration can allow for an extremely complex and diversecaching system without a complicated client invocation to all thesesystems.

With regard to reading data, cache read requests are designed to provideredundant access via one or more caches to data. The image requesthandling subsystem (1310) will make a request to the system cachemanager for image content and meta-data. The system cache manager can beconfigured to read from any number of caches to search for the data.Each system is configured (via runtime modifiable property files) in anorder of search. Failure to locate the requested item on a particularcache will initiate a search on the next specified cache and so on untilall possibilities are exhausted.

As a result, if a system is down (for normal or emergency reasons) thenredundancy is built into the cache system itself. It is also possible tostore differing amounts of cached data on different servers. Forinstance on the first server to be searched, one may only want to store30 days worth of cached images, but on the second server one may want 60days. This provides flexibility in the speed of hardware required forefficient retrieval as well as the aforementioned redundancy.

Hereinafter, aspects of various caches, including main cache (1342),peer cache (1344) and independent cache (1346) will be described.

In accordance with one embodiment of the invention, cache transmissionsare categorized into one of three major types. Each cache may be anycombination of these types depending on what configuration isappropriate.

A main cache is one that receives content requests directly from aninitiating process, i.e., a poller process 1390 or other initiatingcaching process (not shown). A main cache will always pass-through toany configured peers.

A peer cache is one that receives content requests from a main cache.There may be multiple peers for a main cache. A peer may have peer's ofits own. Safeguards have been designed into the system to keep track ofrequests in order to prevent “cache feedback” or “cache looping”—that isprevention of a pass-thru cache request from getting stuck in an endlessloop.

A further cache is an independent cache. An independent cache is onewhich receives a subset of data from another cache. There must be someprocess (workflow triggered, client, or otherwise) which indicates thatan item from one system's cache should be transmitted to anotherindependent cache. This request can push such items to a completelydifferent set of main caches and its peers. An independent cache requestis designed to be on a server which already contains cached data, soindependent requests do not cache on the server where the request ismade. Instead the data gets passed to a remote cache manager for cacheon its server and on to any configured peers of that remote server.

As shown in FIG. 13, the image system 1300 includes an image formathandling layer 1320. The image format handling layer 1320 utilizes anynumber of 3rd party applications in order to provide an interface bywhich programs may request a format change. Some of these formats aregeneralized formats necessary for display or internal manipulation bythe JAVA system and some of them are end-user type formats (such asPDF).

This layer's underlying conversion applications may be replaced,supplemented, or otherwise modified by any suitable application that isnecessary for the system to understand. The layer provides a modulardesign by which such format converters may be plugged in to provideadditional access to needed formats.

The format handling layer stands alone in the system as a service bywhich other components may request conversion without knowing theintimate details of the various formats or how to translate them betweeneach other. At the highest level this can be considered an interpreterbetween languages.

The image system 1300 further includes a generalized image system datamap 1350. The generalized image system provides a generic interfacebetween one or more image systems (1370′, 1370″, 1370′″). In order tokeep track internally of the identifiers available to the public (i.e.,generalized image system identifiers) a persistent data translation mapis utilized.

Whenever a user requests information that requires the system to obtaincontent from one of the underlying image systems (1370), the generalizedimage adapter layer (1360) transparently utilizes the persistent datatranslation map (1350) to find the appropriate system and native systemidentifier containing the data.

The generalized image system data map also provides additionalfunctionality beyond a mere one to one mapping. By using this technologythe generalized image adapter layer 1360 is able to provide a logicalview of the native system's physical images. This allows the users ofthe generalized image system to modify and view document content in amanner more efficient to the day to day business needs than that whichthe physical storage may otherwise provide.

In particular to the insurance industry we frequently receive multipleforms as a single, multi-page image. By using the image data maptechnology it is possible to take these multiple forms and split themout to appear as a number of different documents. While the physicalstorage in the underlying image system(s) (1370) still represents theway it was received, users of the generalized image system can choose toview them as business functional documents. The translation fromphysical storage to logical view is transparent to the end-user.

Note that the system caches (1342,1344,1346) store logical documents.In-fact, everything above the generalized image adapter layer (1320)knows only the logical documents. If a business chooses not to utilizeany of the modification features it is possible for the logical andphysical views to be the same.

In accordance with one embodiment of the invention poller processes maybe used. A poller process is any process which interfaces with thesystem in order to initiate tasks into an external workflow system. Apoller process may also utilize the services provided by the generalizedimage adapter layer (1360) in order to initiate cache requests of imagesvia the system cache manager (1330).

The poller process refers specifically to a process which utilizes thegeneralize image adapter layer's (1320) service API's that look for new,un-handled images in the underlying image systems (1370).

Hereinafter, aspects of the generalized image adapter layer (imagesystem abstraction layer) 1360 will be described in accordance with oneembodiment of the invention. This layer provides transparent access toany number of image systems (1370) via specialized plugins (1380′,1380″,1380′″) conforming to the core services requirements of the adapterlayer. The adapter layer utilizes the data map technology (1350) tocreate a logical view of documents contained in the various imagesystems (1370). The adapter layer 1360 contains the technology capableof performing the necessary merging and splitting of content data intothe logical views.

This layer is the core abstraction between the exposed, generalizedimage world that systems and end-users know and the native image system(1370) world. APIs are provided which transparently provide for theretrieval of content. This layer also provides a set of specificationsby which plug-ins may be written to supply generalized access to anyimage system.

It is the adapter layer 1360 technology working tightly with the datamap technology (1350) that allows routing of the content to any numberof image systems. It is this same technology that also allows one toconvert all the data from one underlying image system 1370 into acompletely different one and turn off the original. By this technologythe end-users and system can continue to operate without any change eventhough the underlying system's storage may be changed.

As shown in FIG. 13, the image system 1300 further includes image systemplug-in adapters (1380′, 1380″, 1380′″), as noted above. An image systemplug-in adapter is a piece of code that conforms to the generalizedadapter layer's (1360) plug-in standards to provide access to anunderlying image system (1370). This code utilizes the underlying imagesystem's (1370) native access methods to provide functions that give theadapter layer (1360) the data it needs.

Each plug-in is a lightweight wrapper around a native image system's(1370) basic functionality that retrieves physical image content and anyavailable image data from the system. This information is thenmanipulated and combined by the adapter layer (1360) technology forabstraction.

As described above, the image system 1300 further includes theunderlying image systems (1370′, 1370″, 1370′″). An underlying imagesystem is any system that is capable of providing for the permanentstorage and retrieval of images and image meta-data. Depending onbusiness needs such image systems may allow for deletion of images.However, such image systems 1370 must be capable of providing permanentstorage.

In accordance with one embodiment of the invention, these systems do notprovide for such things as logical re-organization of images based onbusiness need. All content stored in these systems is in the physicalform that they are received, which may or may not be the most businessfunctional method, i.e., depending on business processes used forcommittal of documents.

The underlying image systems 1370 may vary widely. It is noted that suchunderlying image systems 1370 may include native workflow engines andvery limited capability to perform conversion to differing formats.However, it is noted that generally an underlying image system isfunctionality very basic, providing for storage, manipulation, andretrieval through a proprietary set of interfaces. The storage formatmay be anything, as specified by the provider.

As described above, FIGS. 1-14 show various embodiments of the systemsand methods of the invention. Hereinafter, general aspects of theimplementation of the workflow system 10 will be described.

The system of the invention or portions of the system of the inventionas described above may be in the form of a “processing machine,” such asa general purpose computer, for example. As used herein, the term“processing machine” is to be understood to include at least oneprocessor that uses at least one memory. The at least one memory storesa set of instructions. The instructions may be either permanently ortemporarily stored in the memory or memories of the processing machine.The processor executes the instructions that are stored in the memory ormemories in order to process data. The set of instructions may includevarious instructions that perform a particular task or tasks, such asthose tasks described above in the flowcharts. Such a set ofinstructions for performing a particular task may be characterized as aprogram, software program, or simply software.

As noted above, the processing machine executes the instructions thatare stored in the memory or memories to process data. This processing ofdata may be in response to commands by a user or users of the processingmachine, in response to previous processing, in response to a request byanother processing machine and/or any other input, for example.

As noted above, the processing machine used to implement the inventionmay be a general purpose computer. However, the processing machinedescribed above may also utilize any of a wide variety of othertechnologies including a special purpose computer, a computer systemincluding a microcomputer, mini-computer or mainframe for example, aprogrammed microprocessor, a micro-controller, a peripheral integratedcircuit element, a CSIC (Customer Specific Integrated Circuit) or ASIC(Application Specific Integrated Circuit) or other integrated circuit, alogic circuit, a digital signal processor, a programmable logic devicesuch as a FPGA, PLD, PLA or PAL, or any other device or arrangement ofdevices that is capable of implementing the steps of the process of theinvention.

It is appreciated that in order to practice the method of the inventionas described above, it is not necessary that the processors and/or thememories of the processing machine be physically located in the samegeographical place. That is, each of the processors and the memoriesused in the invention may be located in geographically distinctlocations and connected so as to communicate in any suitable manner.Additionally, it is appreciated that each of the processor and/or thememory may be composed of different physical pieces of equipment.Accordingly, it is not necessary that the processor be one single pieceof equipment in one location and that the memory be another single pieceof equipment in another location. That is, it is contemplated that theprocessor may be two pieces of equipment in two different physicallocations. The two distinct pieces of equipment may be connected in anysuitable manner. Additionally, the memory may include two or moreportions of memory in two or more physical locations.

To explain further, processing as described above is performed byvarious components and various memories. However, it is appreciated thatthe processing performed by two distinct components as described abovemay, in accordance with a further embodiment of the invention, beperformed by a single component. Further, the processing performed byone distinct component as described above may be performed by twodistinct components. In a similar manner, the memory storage performedby two distinct memory portions as described above may, in accordancewith a further embodiment of the invention, be performed by a singlememory portion. Further, the memory storage performed by one distinctmemory portion as described above may be performed by two memoryportions.

Further, various technologies may be used to provide communicationbetween the various processors and/or memories, as well as to allow theprocessors and/or the memories of the invention to communicate with anyother entity; i.e., so as to obtain further instructions or to accessand use remote memory stores, for example. Such technologies used toprovide such communication might include a network, the Internet,Intranet, Extranet, LAN, an Ethernet, or any client server system thatprovides communication, for example. Such communications technologiesmay use any suitable protocol such as TCP/IP, UDP, or OSI, for example.

As described above, a set of instructions is used in the processing ofthe invention. The set of instructions may be in the form of a programor software. The software may be in the form of system software orapplication software, for example. The software might also be in theform of a collection of separate programs, a program module within alarger program, or a portion of a program module, for example Thesoftware used might also include modular programming in the form ofobject oriented programming. The software tells the processing machinewhat to do with the data being processed.

Further, it is appreciated that the instructions or set of instructionsused in the implementation and operation of the invention may be in asuitable form such that the processing machine may read theinstructions. For example, the instructions that form a program may bein the form of a suitable programming language, which is converted tomachine language or object code to allow the processor or processors toread the instructions. That is, written lines of programming code orsource code, in a particular programming language, are converted tomachine language using a compiler, assembler or interpreter. The machinelanguage is binary coded machine instructions that are specific to aparticular type of processing machine, i.e., to a particular type ofcomputer, for example. The computer understands the machine language.

Any suitable programming language may be used in accordance with thevarious embodiments of the invention. Illustratively, the programminglanguage used may include assembly language, Ada, APL, Basic, C, C++,COBOL, dBase, Forth, Fortran, Java, Modula-2, Pascal, Prolog, RUM VisualBasic, and/or JavaScript, for example. Further, it is not necessary thata single type of instructions or single programming language be utilizedin conjunction with the operation of the system and method of theinvention. Rather, any number of different programming languages may beutilized as is necessary or desirable.

Also, the instructions and/or data used in the practice of the inventionmay utilize any compression or encryption technique or algorithm, as maybe desired. An encryption module might be used to encrypt data. Further,files or other data may be decrypted using a suitable decryption module,for example.

As described above, the invention may illustratively be embodied in theform of a processing machine, including a computer or computer system,for example, that includes at least one memory. It is to be appreciatedthat the set of instructions, i.e., the software for example, thatenables the computer operating system to perform the operationsdescribed above may be contained on any of a wide variety of media ormedium, as desired. Further, the data that is processed by the set ofinstructions might also be contained on any of a wide variety of mediaor medium. That is, the particular medium, i.e., the memory in theprocessing machine, utilized to hold the set of instructions and/or thedata used in the invention may take on any of a variety of physicalforms or transmissions, for example. Illustratively, the medium may bein the form of paper, paper transparencies, a compact disk, a DVD, anintegrated circuit, a hard disk, a floppy disk, an optical disk, amagnetic tape, a RAM, a ROM, a PROM, a EPROM, a wire, a cable, a fiber,communications channel, a satellite transmission(s) or other remotetransmission, as well as any other medium or source of data that may beread by the processors of the invention.

Further, the memory or memories used in the processing machine thatimplements the invention may be in any of a wide variety of forms toallow the memory to hold instructions, data, or other information, as isdesired. Thus, the memory might be in the form of a database to holddata. The database might use any desired arrangement of files such as aflat file arrangement or a relational database arrangement, for example.

In the system and method of the invention, a variety of “userinterfaces” may be utilized to allow a user to interface with theprocessing machine or machines that are used to implement the invention.As used herein, a user interface includes any hardware, software, orcombination of hardware and software used by the processing machine thatallows a user to interact with the processing machine. A user interfacemay be in the form of a dialogue screen for example. A user interfacemay also include any of a mouse, touch screen, keyboard, voice reader,voice recognizer, dialogue screen, menu box, list, checkbox, toggleswitch, a pushbutton or any other device that allows a user to receiveinformation regarding the operation of the processing machine as itprocesses a set of instructions and/or provide the processing machinewith information. Accordingly, the user interface is any device thatprovides communication between a user and a processing machine. Theinformation provided by the user to the processing machine through theuser interface may be in the form of a command, a selection of data, orsome other input, for example.

As discussed above, a user interface is utilized by the processingmachine that performs a set of instructions such that the processingmachine processes data for a user. The user interface is typically usedby the processing machine for interacting with a user either to conveyinformation or receive information from the user. However, it should beappreciated that in accordance with some embodiments of the system andmethod of the invention, it is not necessary that a human user actuallyinteract with a user interface used by the processing machine of theinvention. Rather, it is contemplated that the user interface of theinvention might interact, i.e., convey and receive information, withanother processing machine, rather than a human user. Accordingly, theother processing machine might be characterized as a user. Further, itis contemplated that a user interface utilized in the system and methodof the invention may interact partially with another processing machineor processing machines, while also interacting partially with a humanuser.

It will be readily understood by those persons skilled in the art thatthe present invention is susceptible to broad utility and application.Many embodiments and adaptations of the present invention other thanthose herein described, as well as many variations, modifications andequivalent arrangements, will be apparent from or reasonably suggestedby the present invention and foregoing description thereof, withoutdeparting from the substance or scope of the invention.

Accordingly, while the present invention has been described here indetail in relation to its exemplary embodiments, it is to be understoodthat this disclosure is only illustrative and exemplary of the presentinvention and is made to provide an enabling disclosure of theinvention. Accordingly, the foregoing disclosure is not intended to beconstrued or to limit the present invention or otherwise to exclude anyother such embodiments, adaptations, variations, modifications andequivalent arrangements.

1-38. (canceled)
 39. A workflow system for processing an insuranceapplication in an automated manner, the workflow system in the form of anon-transitory tangibly embodied processing machine, the workflow systemcomprising: an interface portion tangibly disposed in the processingmachine, the interface portion inputting application information intothe workflow system for processing by the workflow system; a workflowlooping portion tangibly disposed in the processing machine, theworkflow looping portion performing processing, the processingincluding, in sequence: performing underwriting processing to effectunderwriting of the insurance application based on the applicationinformation, the performing underwriting processing including:monitoring the underwriting processing to determine whether theunderwriting processing is completed, and forwarding the insuranceapplication to perform issue processing subsequent to the determiningthat the underwriting processing is completed; performing issueprocessing to effect issue of the insurance application, the performingissue processing including: monitoring the issue processing to determinewhether the issue processing is completed; and forwarding the insuranceapplication to perform settlement processing subsequent to thedetermining that the issue processing is completed; and performingsettlement processing to effect settlement of the insurance application,the performing settlement processing including: monitoring thesettlement processing to determine whether the issue processing iscompleted; and a rules logic portion tangibly disposed in the processingmachine, the rules logic portion controlling the implementation of rulesapplied to the processing of the insurance application as the insuranceapplication passes through the automated processing; and the performingunderwriting processing, performing issue processing and performingsettlement processing are each performed in an automated manner toconstitute automated processing of the insurance application, such thatthe automated processing includes the performing underwritingprocessing, performing issue processing and performing settlementprocessing.
 40. The workflow system of claim 39, further including await state portion, the wait state portion imposing wait states on theautomated processing such that the automated processing is suspendeduntil the wait state imposed by the wait state portion is ended.
 41. Theworkflow system of claim 40, wherein the wait state portion imposes thewait state because the wait state portion identifies that there isinsufficient information available to underwrite the insuranceapplication, the wait state being imposed in the underwritingprocessing.
 42. The workflow system of claim 41, wherein the wait stateportion ends wait state once information is received to cure theinsufficient information, and subsequently, the workflow looping portionre-starts the underwriting processing.
 43. The workflow system of claim42, wherein the received information is a document.
 44. The workflowsystem of claim 40, wherein the wait state portion imposes the waitstate because the wait state portion identifies that there is a requiredtask to be performed by a person.
 45. The workflow system of claim 40,wherein the wait state portion imposes the wait state because the waitstate portion identifies that required is the resolution of at least oneselected from the group consisting of a case management issue, a legalissue and an administrative issue.
 46. The workflow system of claim 39,wherein the workflow system further includes a task logic portion, thetask logic portion identifying, based on particulars of an insuranceapplication, a need for completion of a task to effect the automatedprocessing.
 47. The workflow system of claim 46, wherein the task isassociated with a document used in the automated processing.
 48. Theworkflow system of claim 47, wherein the task is a discrepancy in thedocument requiring human intervention.
 49. The workflow system of claim46, wherein the task logic portion identifies the task as an itemrequiring human review.
 50. The workflow system of claim 46, wherein thetask logic portion identifies the task based on: identifying a change toinformation used in the automated processing by a first person; andidentifying that a second person is required to review the change underthe automated processing, the task being a verify task.
 51. The systemof claim 46, further including: a wait state portion, the wait stateportion imposing a wait state on the automated processing such that theautomated processing is suspended until the wait state imposed by thewait state portion is ended; and the wait state portion imposes the waitstate because there is a task to be performed; and wherein the tasklogic portion effects form validation processing, the form validationprocessing: identifying a change in a changed document in the automatedprocessing; wiping clean all tasks associated with the changed document;scrubbing information in the changed document; and checking the changeddocument for deficiencies.
 52. The workflow system of claim 46, whereinthe task logic portion making an association to effect completion of thetask; and the making an association to effect completion of the taskincludes the task logic portion associating the identified task to aperson.
 53. The workflow system of claim 46, wherein the task logicportion making an association to effect completion of the task; and themaking an association to effect completion of the task includes the tasklogic portion associating the identified tasks to a group.
 54. Theworkflow system of claim 46, wherein the task logic portion making anassociation to effect completion of the task; and the making anassociation to effect completion of the task includes the task logicportion disposing the task for access by at least one of a person and agroup.
 55. The workflow system of claim 46, wherein the task logicportion generates indicia that is associated with an insuranceapplication, and provides for a user to access the workflow system, andidentify their need to perform the task, based on the indicia.
 56. Theworkflow system of claim 55, wherein the task logic portion placesinformation in a queue so as to identify the task to a person, who isidentified to complete the task.
 57. The workflow system of claim 39,further including a case management portion, the case management portionallowing a user to enter instructions to terminate processing of aninsurance application in the workflow system; and the case managementportion forwarding the insurance application to an external system,outside the workflow system, based on the instructions; and theinsurance application being forwarded to the external system for furtherprocessing in the external system.